Connection Pool
コネクションプール_
connectionを先に理解している必要がる
DB server側視点で見ると、同時に接続できるconnection数には上限がある
この上限を超えると接続を受け付けなくなる
そこで、あらかじめ接続した状態を用意しておいて、それを貸し出すことで、使うときに接続する手間を減らす
client側で制御する
カーネルにせよ、データベース層にせよ、結局はメモリなどのハードウェアリソースをいたずらに消費しないための制限である。 メモリが溢れてディスクへのスワップが発生し、データベースサーバが停止すると、システム全体に影響する。 システム全体に影響を与えるくらいなら、クライアント側で上限を設けておいて、多少の接続待ちが起きてもよいことにする。
ここでの「client」はWeb Appサーバーのこと
2種類の実装
https://blog.yuuk.io/entry/architecture-of-database-connection#:~:text=は大きく-,%EF%BC%92種類,-ある%E3%80%82これらの%EF%BC%92
ドライバ型
リクエスト処理用のthread pool以外に、DB接続用のthread poolを作成する
各スレッドのローカル変数に接続オブジェクトを持たせる
プロキシ型
web app serverとDB serverの間にProxyを挟む
webapp → proxy → DB
proxy → DBは、常時接続
webapp → DBはどちらでも良い
常時接続でも、reqごとに接続でも
#??
「接続にコストがかかる」という感覚がわからない
それはconnectionの話
DBとの接続と切断のような概念を理解していないとだめだmrsekut.icon
コネクションってなに?というのを知らないとpoolの話は理解できない
具体的にどういう処理をやっているの?
なんでpoolである必要があるの?
というかまずpoolの中に複数のconnectionがあるという理解は合っている?
その上で、なんで複数必要なのか?
1つのconnectionを確立しっぱなしにしておいて、reqごとにそれを割り当てるのでは問題が起きる?
デメリット
Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
わかりやすい
https://please-sleep.cou929.nu/go-sql-db-connection-pool.html
https://qiita.com/snaka/items/b6e7500c96e04c131d9e
https://yakst.com/ja/posts/5444
https://wyukawa.hatenablog.com/entry/20131116/1384621867
https://naoya-2.hatenadiary.org/entry/20060912/1158058322